1. Field of the Invention
The present invention relates to a cross-software development/maintenance system for developing a cross-software program for a target computer system having no software development environment (e.g., a middle-capacity electronic exchange, or the like), using a host computer and transferring it to the target computer system.
2. Description of the Related Art
As a result of the rapid progress made in the development of information processing systems, various exchange systems now tend to employ electronic technologies, leading to the development of electronic exchanges employing a computer as part of an exchange control section. Exchange systems of this type are requested to have maximum processing capability for exchange, and their architectures are specified to be dedicated to serve as exchanges. For this reason, electronic exchanges (i.e., from small-capacity exchanges through larger-capacity devices) have themselves had no software development environment, so that up until now, development of software programs for electronic exchanges (development of a source program, development of an object program, debugging, development of an execution load module, and the like) has been performed by a host computer system, the compiled object software program then being transferred to a target computer system (in this case, an electronic exchange) to be executed.
Conventionally, software file transfer between a host computer system and a target computer system will now be described, with reference to FIG. 1. In FIG. 1, in response to an instruction of a terminal 3, a host computer system 1 develops a software program to be executed by a target computer system 2 in the form of an execution load module.
The software program (execution load module) developed by the host computer system 1 is transferred to the target computer system 2 through a communication line 5 connected to an in circuit emulator (ICE) 4. The ICE 4 is normally used for debugging of the target computer system 2. The target computer system 2 stores the received execution load module in a secondary storage device, e.g., a floppy disk device 11 under the control of a main CPU 10.
According to another method of transferring an execution load module to a target computer system, a ROM writer 6 is connected to the host computer system 1, the execution load module is written in a ROM (Read Only Memory) chip 7 by the ROM writer 6, and the ROM chip 7 is mounted in the target computer system 2.
According to still another method, a floppy disk device (FDD) 8 is connected to the host computer system 1, and the execution load module from the host computer system 1 is converted to a recording format of the FDD 8 and is written in a floppy disk (FD) 9. The floppy disk 9 written with the execution load module is set in an FDD of the target computer system 2, thus transferring a cross-software file.
However, when an execution load module is transferred through a commercially available ICE 4, its information transfer speed is limited. Moreover, the greater the volume of a file to be transferred, the greater the amount of time required to transfer an execution load module. Therefore, when frequent changes must be made to a software program as a result of debugging, use of the above method is not practical.
When the target computer system 2 comprises a multi-CPU configuration, ICEs 4 are connected in units of CPUs. Since an execution load module must be transferred through these ICEs 4, communication procedures become complicated. Because of this, the target computer system 2 cannot be operated until the execution load modules have first been transferred to the plurality of CPUs.
On the other hand, when an execution load module is supplied to the target computer system 2 through the FD 9, and the software volume is large, a large number of FDs 9 are required, resulting in long read/write time. Furthermore, software change procedures become complicated.
Supply of an execution load module using the ROM chip 7 is effective when a software volume is small. However, it takes much time to mount the ROM chip 7 on the target computer system 2, and a large number of chips are required to transfer a program of a large volume (e.g., transfer of a program requiring a storage capacity of 1 Mbyte). This method cannot be applied to a practical application.
In order to solve these problems, after an execution load module is supplied to the target computer system 2, debugging may be performed on the target computer system 2. However, since the target computer system 2 has poor software development environment, it must debug the execution software module using object codes, i.e., must perform so-called patch-work. For this reason, debugging efficiency is very poor. When a source program is written in a high-level language, it is difficult to correct it on the target computer system 2 using the assembler or machine language. Thus, this disturbs software development in a high-level software language.
The above-mentioned problems are posed not only in a software development process but in a test process after hardware is completed or in a software change process after a product is delivered